Cryptographic devices include, by way of example, user authentication tokens. Authentication tokens are typically implemented as small, hand-held devices that display a series of passwords over time. These passwords, which may be one-time passwords, are more generally referred to herein as tokencodes. A user equipped with such an authentication token reads the currently displayed password and enters it into a computer or other element of an authentication system as part of an authentication operation. This type of dynamic password arrangement offers a significant security improvement over authentication based on a static password.
Conventional authentication tokens include both time-based tokens and event-based tokens. The latter are also referred to herein as event-triggered tokens. In a typical time-based token, the displayed passwords are based on a secret value and the time of day. A verifier with access to the secret value and a time of day clock can verify that a given presented password is valid. Event-based tokens generate passwords in response to a designated event, such as a user pressing a button on the token. Each time the button is pressed, a new password is generated based on a secret value and an event counter. A verifier with access to the secret value and the current event count can verify that a given presented password is valid.
Passwords can be communicated directly from the authentication token to a computer or other element of an authentication system, instead of being displayed to the user. For example, a wired connection such as a universal serial bus (USB) interface may be used for this purpose. Wireless authentication tokens are also known. In such tokens, the passwords are wirelessly communicated to a computer or other element of an authentication system. These wired or wireless arrangements, also referred to herein as connected tokens, save the user the trouble of reading the password from the display and manually entering it into the computer.
Additional details of exemplary conventional authentication tokens can be found in, for example, U.S. Pat. No. 4,720,860, entitled “Method and Apparatus for Positively Identifying an Individual,” U.S. Pat. No. 5,168,520, entitled “Method and Apparatus for Personal Identification,” and U.S. Pat. No. 5,361,062, entitled “Personal Security System,” all of which are incorporated by reference herein.
Prior to accepting a password generated by an authentication token, a computer may require the user to enter a personal identification number (PIN) or other static access code. This provides an additional security factor, based on something the user knows, thereby protecting against unauthorized use of a token that is lost or stolen.
It is not uncommon, however, for a user to forget his or her PIN, and thereby be unable to use the token. Also, if an incorrect value for this PIN is entered too many consecutive times, the token will typically lock itself In such situations, a user may be required to physically transport the token to a security administrator to reset the PIN or unlock the token. Alternatively, a user may be provided with a PIN unlocking key (PUK) that allows the user to reset the PIN or unlock the token.
Both of these conventional approaches suffer from drawbacks. The first approach can take considerable time, and is burdensome for administrators. This would be a particularly cumbersome approach if the user is remote from the administrator, and if the token provided additional functions such as acting as an employee badge.
In the second approach, allowing user access to the PUK provides a “back-door” to the token that may be undesirable, particularly if the PUK can also be used for other administrative tasks on the token, or is the same for multiple tokens. A PUK may be viewed as an administrator PIN for the token, and the idea of allowing a user to know an administrator PIN is generally undesirable. Once an administrator has released the PUK to the user, the administrator cannot be sure that the user has not further distributed the PUK, nor left a copy of the PUK unprotected. This degrades the overall security of the approach.
The conventional approaches described above are similarly problematic with regard to performance of other administrative operations on authentication tokens, such as configuration changes or provisioning of new information other than updated PINs.
Although security may be enhanced to some extent through encryption of commands sent to the token, such encryption is suitable only for connected tokens, and in any case fails to overcome the fundamental deficiencies noted above.
Accordingly, what is needed is an improved approach to remote administration of authentication tokens and other cryptographic devices, which avoids the problems of the conventional approaches.